The proliferation of computer networks has made it necessary to have some way of efficiently managing these networks. Many businesses have turned to outside service providers of Managed IP Network Services to manage their networks. Among other tasks, the service providers remotely monitor customers' networks for problems that may arise using a central management server (i.e., the “manager.”)
In a network using the Internet Protocol (IP), the manager has a single IP address that is associated with a physical interface at the network element. Outgoing IP data packets (“datagrams”) sent from the manager include this IP address as the source IP address. Incoming IP data packets received by the manager include this IP address as the destination IP address.
The managed networks (i.e., “agents” or “customer networks”), which are managed by the service provider, have network elements/devices, such as network servers, routers, switches, hubs, hosts, probes, etc. that each have an IP address identifier. The service provider must be able to address each of the network elements on the managed networks using the IP addresses of these network elements.
Service providers face a challenge in centrally managing multiple IP networks when some of the network elements in the various networks are assigned identical IP addresses. This is because network management applications and the IP protocol stacks on which they run operate under the assumption that IP addresses, are unique for each network element. This assumption is correct with respect to an individual customer's private network in which each machine does have a unique IP address. However, the assumption may be incorrect in a situation where a service provider remotely manages networks for multiple customers. Many of these customers may deploy private networks that each use certain identical ranges of addresses to identify their machines.
The use of duplicate IP addresses results from the IP address scheme. In this scheme, the notation “10.0.0.0” is the standard way of expressing an Internet address. Each of the four numbers in the address is internally stored as an 8 bit value, so each number may have a value from 0 to 255 inclusive. Addresses are generally used in contiguous ranges. The notation “10.0.0.0/8” describes those addresses whose top 8 bits are the number 10, and whose remaining (24) bits can be any other combination of numbers. Another commonly used terminology for such an address range is a “network number”: 10.0.0.0/8 is “network 10”.
While most Internet addresses are assigned by an international authority, and are only used for one machine in the entire world, several ranges—the 10.0.0.0/8 and 192.0.0.0/24 ranges among them—are explicitly left unassigned; they are generally referred to as private. Addresses in these ranges can be used for any machine, as long as the networks to which those machines are connected are configured so that the addresses do not “escape” to the greater Internet. It is these IP addresses that can be duplicated among networks. The Address Translation Gateways described below were designed to allow machines with addresses of this sort a way to communicate with the greater Internet.
A management application for managing multiple private networks operating in the presence of non-unique IP addresses must be able to recognize the distinct network elements that have duplicate IP addresses. If the network elements that share the same address could not be distinguished, a topology map at the service provider or elsewhere, which maps the network elements on the various networks, will incorrectly show that systems in each of the customer networks are connected, when, in reality, they are totally unrelated. Such phantom connectivity is the result of the systems sharing the same IP network number. As a result, data may be incorrectly routed to an unintended network element or may be unroutable due to the ambiguity in the intended destination.
Additionally, if a network management application polls one of multiple devices that are assigned the same IP address but are in different customer networks, the management application must be able to determine which of the multiple devices actually received the poll and sent a response that is received. The Simple Network Management Protocol (SNMP) (defined in RFC 1157 published by the IETF (Internet Engineering Task Force)), and the Internet Control Message Protocol (ICMP) (RFC 792), are two commonly-used protocols that permit polling.
Moreover, in a protocol, such as SNMP, a network element may send a notification to the network manager about a change in status of the device or about some event that has occurred without the manager first sending a request for this information. In SNMP, such a notification is referred to as an SNMP “trap”. A management application must be able to tell which managed network generated a trap when the trap's source address is duplicated by multiple systems in different customer networks.
Managing networks with duplicate IP addresses has been cumbersome. There are two common prior art approaches that service providers have employed: one may be referred to as the “Hardware Method” and the other is the “Address Translation Gateways” method. Both of these approaches are work-arounds that eliminate (or at least minimize) the problem.
The so-called Hardware Method is a brute-force approach that tries to solve the problem with computer hardware. In this method, the service provider deploys multiple hardware platforms at the service provider each running a separate copy of the management application. Customer A's network is managed from one platform, customer B's network from another platform, and so on. Static routes are configured on each platform so that packets from the first hardware platform and management application go to customer A's network and packets from the second hardware platform and management application go to customer B's network.
This approach has two significant disadvantages. First, each new customer that comes online requires a new, dedicated hardware platform which greatly increases the cost. Second, the end result is multiple isolated management applications. This makes it difficult for the service provider to centralize operations management.
Another approach uses Address Translation Gateways to eliminate the address duplication. Using this approach, the service provider provides an address translation table at the gateways to translate the common addresses either to IP addresses assigned exclusively to the service provider, or to non-exclusive IP addresses. In the latter case, the service provider must isolate its management network from the greater Internet in the event that it duplicates someone else's addresses.
As an example of the Address Translation approach, assume customers A and B use the address range 10.1.0.0/16. A software translation table is set up that maps 10.1.0.0/16 for customer A to 11.1.0.0/16, which in this example is an IP address that is unique, i.e. not duplicated, in the managed networks and the management application. A similar table is set up for customer B that maps 10.1.0.0/16 to 12.1.0.0/16, another otherwise unused IP address. In the address translation method, the management application for managing the customer networks is unaware of the real IP addresses of the customer devices. Instead, the management application is told that customer A devices are in the range 11.1.0.0/16, and that customer B's devices are in the range 12.1.0.0/16. Static routes are set up on the management platform to route traffic for network 11.1.0.0/16 to a special-purpose hardware device that has unambiguous connectivity to customer A's network. A similar route to a second device is configured for customer B. The special-purpose hardware device uses the address translation table to translate packets sent to and received from the customer network.
Address translation works well only when the number of addresses that must be translated in any reasonably short interval of time is a small fraction of the potential addresses in the private network. It would be very difficult for a service provider to find enough addresses to “cover” all the addresses used by even a small number of customers with large networks. In fact, one reason to use shared addresses such as 10.0.0.0/8 is that it is difficult, if not impossible, for anyone to get large address range assignments under the IP address scheme that uses a set of four numbers. Additionally, a network management application by its very nature is likely to need to reach a large fraction of all hosts in the managed network on a regular basis. This would make the address translation method difficult to apply for network management even if all other problems could be solved.
These other problems include a requirement for special-purpose hardware platform to implement the address translation, so the address translation method does not eliminate the per customer hardware expenditure. Second, in using the SNMP protocol packet payload translation is required to translate the address from the common IP address contained within the payload of the IP packet. This ensures that no evidence of the customer's real IP addresses are seen by the management application, which may confuse the management application as to the source of the packet.
For example, management information base (MIB) tables at the special-purpose hardware device that performs address translation, like the MIB-2 ipAddrTable, contain keys or row values that represent IP addresses for network elements that are to be managed. The translator must intercept the response from a managed network to any poll for such a MIB variable. The IP address must then be located within the response payload of a packet and properly translated before the response may be sent to the management application. This processing introduces an unwanted run-time overhead that slows down polling. More importantly, the service provider must be aware of all MIB variables accessed by the management application in order to determine if any need to be translated. This creates an undesirable administrative overhead.
Perhaps the most crucial drawback to the address translation method is the fact that the management application is completely unaware of the real addressing scheme of the customer. Therefore, alarms that are generated for network failures or troubles have no meaning to operations staff without even more translation processes that can manipulate the notifications coming out of the management application.
In view of the shortcomings of the prior art, it would be advantageous to have a better solution to managing multiple private networks that use common IP addresses. Such a solution should:                (1) allow a service provider who provides the management application to manage identically addressed customer networks from a single management hardware platform;        (2) not require the service provider to deploy customer-specific hardware elements;        (3) permit the isolation of the customer network topologies, even though they occupy the same IP address space;        (4) report failures using the native addressing of the customer networks; and        (5) permit the use of SNMP and ICMP polling originating from the single hardware platform, as well as the unambiguous processing of incoming traps received on the single hardware platform, without ambiguity due to the overlapping IP addressing.        
Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims.